The present invention pertains to interception by an automatic distributed partitioning system of calls from client units of an application program to unit activation functions.
Fueled by the growing importance of the Internet, interest in the area of distributed systems (two or more computers connected by a communications medium, alternatively termed a xe2x80x9cdistributed computing environmentxe2x80x9d) has increased in recent years. Programmers desiring to take advantage of distributed systems modify existing application programs to perform on distributed systems, or design applications for placement on distributed systems.
A distributed application is an application containing interconnected application units (xe2x80x9cunitsxe2x80x9d) that are placed on more than one computer in a distributed system. By placing units on more than one computer in a distributed system, a distributed application can exploit the capabilities of the distributed system to share information and resources, and to increase application reliability and system extensibility. Further, a distributed application can efficiently utilize the varying resources of the computers in a distributed system.
Various types of modular software, including software designed in an object-oriented framework, can conceivably be distributed throughout a distributed system. Object-oriented programming models, such as the Microsoft Component Object Model (xe2x80x9cCOMxe2x80x9d), define a standard structure of software objects that can be interconnected and collectively assembled into an application (which, being assembled from component objects, is herein referred to as a xe2x80x9ccomponent applicationxe2x80x9d). The objects are hosted in an execution environment created by system services, such as the object execution environments provided by COM. This system exposes services for use by component application objects in the form of application programming interfaces (xe2x80x9cAPIsxe2x80x9d), system-provided objects and system-defined object interfaces. Distributed object systems such as Microsoft Corporation""s Distributed Component Object Model (DCOM) and the Object Management Group""s Common Object Request Broker Architecture (CORBA) provide system services that support execution of distributed applications.
In accordance with object-oriented programming principles, the component application is a collection of object classes which each model real world or abstract items by combining data to represent the item""s properties with functions to represent the item""s functionality. More specifically, an object is an instance of a programmer-defined type referred to as a class, which exhibits the characteristics of data encapsulation, polymorphism and inheritance. Data encapsulation refers to the combining of data (also referred to as properties of an object) with methods that operate on the data (also referred to as member functions of an object) into a unitary software component (i.e., the object), such that the object hides its internal composition, structure and operation and exposes its functionality to client programs that utilize the object only through one or more interfaces. An interface of the object is a group of semantically related member functions of the object. In other words, the client programs do not access the object""s data directly, but instead call functions on the object""s interfaces to operate on the data. Polymorphism refers to the ability to view (i.e., interact with) two similar objects through a common interface, thereby eliminating the need to differentiate between two objects. Inheritance refers to the derivation of different classes of objects from a base class, where the derived classes inherit the properties and characteristics of the base class.
A client program requests instantiation of a component application object locally or on a remote computer using system-provided API functions and a set of standard, system-defined component interfaces based on class and interface identifiers. In particular, the client program can call xe2x80x9cactivation mechanismxe2x80x9d API functions (xe2x80x9cactivation functionsxe2x80x9d) to request local or remote creation of a component using assigned class and interface identifiers. In response to a request, the activation mechanism API creates an instance of the component at the appropriate location and returns a pointer of the requested interface to the client program.
An application containing easily identifiable and separable units is more easily distributed throughout a distributed system. One way to identify separable units is to describe such units with structural metadata about the units. Metadata is data that describes other data. In this context, structural metadata is data describing the structure of application units. Further, application units are desirably location-transparent for in-process, cross-process, and cross-computer communications. In other words, it is desirable for communications between application units to abstract away location of application units. This flexibly enables the distribution of application units.
The partitioning and distribution of applications are problematic and complicated by many factors.
To partition an application for distribution, a programmer typically determines a plan for distributing units of the application based on past experience, intuition, or data gathered from a prototype application. The application""s design is then tailored to the selected distribution plan. Even if the programmer selects a distribution plan that is optimal for a particular computer network, the present-day distribution plan might be rendered obsolete by changes in network topology. Moreover, assumptions used in choosing the distribution plan might later prove to be incorrect, resulting in an application poorly matched to its intended environment.
Generally, to distribute an application, one can work externally or internally relative to the application. External distribution mechanisms work without any modification of the application and include network file systems and remote windowing systems on a distributed system. Although external distribution mechanisms are easy to use and flexible, they often engender burdensome transfers of data between nodes of the distributed system, and for this reason are far from optimal. Internal distribution mechanisms typically modify the application to be distributed in various ways. Internal distribution mechanisms allow optimized application-specific distribution, but frequently entail an inordinate amount of extra programmer effort to find an improved distribution and modify the application. Further, internal systems frequently provide ad hoc, one-time results that are tied to the performance of a particular network at a particular time.
An automatic distributed partitioning system (ADPS) works internally relative to an application to partition application units, and works automatically or semi-automatically to save programmer effort in designing distributed applications.
In the 1970""s, researchers postulated that the best way to create a distributed application was to use a compiler in a run time environment to partition the application, and to provide the exact same code base to each of plural distributed machines as used on a single machine to execute the distributed application. After analyzing the structure of procedures and parameters in the source code of an application, metadata describing the structure of an application were generated from the application source code. Using this metadata, these ADPSs profiled the application and generated a communication model for the application. The Interconnected Processor System (ICOPS) is an example of an ADPS designed in the 1970""s. The Configurable Applications for Graphics Employing Satellites (CAGES) also supported creation of distributed applications, but did not support automatic application profiling at all. A more recent example of an ADPS is the Intelligent Dynamic Application Partitioning (IDAP) System. ICOPS, CAGES, and IDAP suffer from numerous drawbacks relating to the universality, efficiency, and automation of these systems.
An ADPS is a type of instrumentation system. An instrumentation system provides a layer of functionality on top of an application for measuring and recording information about the application, or for somehow modifying the execution of the application. An ADPS instruments an application in order to profile the application and modify execution of the application during distributed execution. ICOPS, CAGES, and IDAP do not provide instrumentation for an application in which, during execution, units are dynamically created by other units and destroyed when no longer needed. Neither ICOPS, CAGES, nor IDAP provides a mechanism for intercepting function calls from client units of an application to unit activation functions for dynamically creating units. In particular, neither ICOPS, CAGES, nor IDAP uses in-line redirection of calls to unit activation functions for dynamically creating units.
Techniques for intercepting function calls include application source code replacement, application binary code replacement, dynamic link library redirection, dynamic link library replacement, breakpoint trapping of function calls, and inline redirection. ICOPS, CAGES, and IDAP do not apply any of these techniques for intercepting function calls to the interception of function calls to unit activation functions.
The present invention pertains to interception of calls to unit activation functions by an automatic distributed partitioning system (ADPS). By intercepting function calls to unit activation functions by units of an application program, the ADPS partitions and distributes units of application programs in which units are dynamically created and destroyed.
A unit activation function dynamically creates units. The unit activation function can be provided, for example, by a system service library. An application program comprising plural units includes at least one function call from a client unit to a unit activation function. The ADPS redirects the function call to an instrumentation unit activation function provided by the ADPS so that when the client unit calls the unit activation function, the instrumentation unit activation function is invoked. The instrumentation unit activation function can, for example, determine a location for a unit to be activated, then cause the unit to be activated there.
The ADPS can redirect the function call to the unit activation function by replacing the original function call in the application program source or binary code. When the application program uses load-time dynamic linking, the ADPS can replace a reference to the unit activation function in the import section of the application binary. Alternatively, the ADPS can replace the unit activation function itself with the instrumentation unit activation function, even replacing a system service library containing the unit activation function if necessary. The ADPS can insert a breakpoint trap in the unit activation function to trigger instrumentation whenever the unit activation function is called.
In an illustrated embodiment of the present invention (the xe2x80x9cCOIGN systemxe2x80x9d), the ADPS uses inline redirection of function calls to a unit activation function. A detour function contains instructions for instrumentation. The ADPS creates a trampoline function out of one or more instructions from the beginning of the unit activation function. After these instructions in the trampoline function, the ADPS places a Jump instruction for transferring control to a spot in the unit activation function following the instructions copied to the trampoline function. The ADPS places a jump instruction to the detour function at the beginning of the unit activation function, for example with a binary rewriter. When a client unit calls the unit activation function, the jump instruction transfers control to the detour function, and the detour function executes.
In the illustrated embodiment, when the instructions of the unit activation function come from a fixed length instruction set, the first instruction of the trampoline function is the first instruction of the unit activation function. The jump in the trampoline function transfers control to the second instruction in the modified unit activation function, whose first instruction is a jump to the detour function.
In the illustrated embodiment, when the instructions of the unit activation function come from a variable length instruction set, the ADPS determines the size of the jump instruction to the detour function. One or more instructions from the beginning of the unit activation function are copied to the trampoline function, where any instructions that will be overwritten by the jump instruction to the detour function are copied. The jump instruction to the unit activation function from the trampoline function transfers control to a spot following the last copied instruction of the unit activation function.
In the illustrated embodiment, the detour function executes instructions for classifying a unit to be created, and determining a location in a distributed computing environment for the unit to be created. If the unit is to be activated locally, the detour function calls the trampoline function to bypass the instrumentation and activate the unit locally. In the trampoline function, the first instructions of the original unit activation function execute, then control passes to the unit activation function for execution of the remaining instructions. If unit is to be activated remotely, the function call is routed to the appropriate remote location. In an alternative embodiment, the detour function executes instructions for other instrumentation. When the unit activation function finishes, it can transfer control back to the detour function or another instrumentation function.
In the illustrated embodiment, the trampoline function is directly callable from the client unit. If the client unit directly calls the trampoline function, the first instructions of the original unit activation function execute, then control passes to the unit activation function for execution of the instructions following the copied instructions. By directly calling the trampoline function, the client unit bypasses the detour function.
In the illustrated embodiment, the creation of the trampoline function and modification of the unit activation function occur at run time. Alternatively, these operations occur before run time.